home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / hardware-part1 / 2352 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.4 KB

  1. Path: news.delcoelect.com!c23jwd
  2. From: c23jwd@kocrsv01.delcoelect.com (Jeffrey William Davis)
  3. Newsgroups: comp.sys.amiga,comp.sys.amiga.hardware,comp.sys.amiga.programmer,no.amiga
  4. Subject: Re: FWD: Fate of 68080
  5. Date: 24 Jan 1996 20:24:00 GMT
  6. Organization: Delco Electronics Corp.
  7. Distribution: usa
  8. Message-ID: <4e64h0$q49@kocrsv08.delcoelect.com>
  9. References: <4d3c27$n6c@rs18.hrz.th-darmstadt.de> <1141.6593T1100T790@norconnect.no>
  10. NNTP-Posting-Host: koptsw19.delcoelect.com
  11.  
  12. In article <1141.6593T1100T790@norconnect.no>,
  13. Kenneth C. Nilsen <kenneth@norconnect.no> wrote:
  14. >>The current/near future top-of-the-line is the PPC 604@150 MHz. 
  15. >>The 300 MHz was foreseen for the 64-bit PPC 620, but the situation about this
  16. >>beast is unclear since the projected performance gain is not enough these
  17. >>days. Instead a design rework will be done, maybe they call it 630 or so.
  18. >>Anyway the race for MHz sounds silly to me, since the memory can't keep pace
  19. >>with it, except for large (and expensive) caches. 700 MHz is science fiction 
  20. >>I'd say.  
  21. >
  22. >Yeah, you got a point. But wouldn't it be possible to write data parallell to
  23. >memory, I mean, using double memory bus writes so that in principle you can
  24. >write not 1 byte, but 2 bytes simultainously or even 4 bytes etc. (hope you
  25. >get the picture) ?
  26.  
  27. This 'principle' which you loosely describe is already commonly done, and
  28. 64, 128bits (16 bytes) or more are written and read simultaneously.
  29. Writing data has never really been the problem, it's READING it that
  30. causes a bottleneck that is tough to get around.
  31.  
  32. When writing, the data can be handed to a cache that will write it whenever
  33. it has the time.  If a read is attempted on that data while it is still
  34. in the cache, you simply deliver (read) the cache value.  Granted, there
  35. are numerous ways to get data into the cache (including reads) but that's
  36. not important here.
  37.  
  38. When reading, the processor expects the data NOW.  There is a limited
  39. amount of time between when the processor is able to give an address and
  40. when it expects the data to be ready.  If you take longer than this to
  41. retrieve the data, the processor has to wait; hence, wait-states.
  42.  
  43. With RAM technology rapidly falling behind processor speed, we need to
  44. somehow 'predict' which piece of data the processor will want and (at
  45. the very least) begin reading it before the processor even asks for it.
  46. Then place it in a device (cache) which can deliver it to the processor
  47. more quickly.  This is where the 'expensive' cache comes in.
  48.  
  49. CPUs having asynchronous address and data busses make it easier to
  50. manage the high MHz, since it takes less time to latch an address than
  51. it does to complete a R/W cycle on the data bus.  This allows you to
  52. grab multiple addresses and begin working on them simultaneously while
  53. the data busses are saturated; continually trying to keep the data bus
  54. from ever having to wait.
  55.  
  56. Unfortunately, the only perfect prediction would be one that could
  57. deliver any piece of memory on demand as fast as the processor can
  58. accept it - hence the < 1ns DRAM @ 700MHz!  Not likely to happen in
  59. the near future.  The further the CPU MHz fly past the current RAM
  60. technology, the more rediculous it becomes.
  61.  
  62. -- 
  63. =======================================================================
  64. Jeffrey W. Davis (317)451-0503   Domain: c23jwd@eng.delcoelect.com
  65. Software Engineer                UUCP:   deaes!c23jwd
  66. Delco Electronics Corporation    GM:     8-322-0503         Mail: CT40A
  67.